1. Field of the Invention
The present invention relates to a distributed measurement system for an embedded automotive acquisition device.
2. Description of the Related Art
In such systems the transport control protocol (TCP) is widely used for the reliable transport of measurement, calibration and diagnostic (MCD) data between embedded acquisition devices connected to automotive electronic control units (ECUs) and automotive development software tools running on personal computers (e.g. INCA from ETAS GmbH).
The embedded acquisition devices are often co-located to the ECU (device under test, DUT) and must operate under the same harsh environmental conditions as the ECU itself. Supplied from the vehicle's battery, the power consumption of the acquisition devices has to be low in order to stay in stand-by mode without stressing the battery too much, in order to be able to capture an ECU's start-up behavior.
The Transmission Control Protocol (TCP) is one of the core protocols of the Internet Protocol Suite. TCP is one of the two original components of the suite, complementing the Internet Protocol (IP), and therefore the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered delivery of a stream of octets from a program on one computer to another program on another computer. TCP is the protocol used by major Internet applications such as the World Wide Web, email, remote administration and file transfer. Other applications, which do not require reliable data stream service, may use the User Datagram Protocol (UDP), which provides a datagram service that emphasizes reduced latency over reliability.
The protocol corresponds to the transport layer of TCP/IP suite. TCP provides a communication service at an intermediate level between an application program and the Internet Protocol (IP). That is, when an application program desires to send a large chunk of data across the Internet using IP, instead of breaking the data into IP-sized pieces and issuing a series of IP requests, the software can issue a single request to TCP and let TCP handle the IP details.
IP works by exchanging pieces of information called packets. A packet is a sequence of octets and consists of a header followed by a body. The header describes the packet's destination and, optionally, the routers to use for forwarding until it arrives at its destination. The body contains the payload data.
Due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets can be lost, duplicated, or delivered out of order. TCP detects these problems, requests retransmission of lost data, rearranges out-of-order data, and even helps minimize network congestion to reduce the occurrence of the other problems. Once the TCP receiver has reassembled the sequence of octets originally transmitted, it passes them to the application program. Thus, TCP abstracts the application's communication from the underlying networking details.
TCP is utilized extensively by many of the Internet's most popular applications, including the World Wide Web (WWW), E-mail, File Transfer Protocol, Secure Shell, peer-to-peer file sharing, and some streaming media applications.
TCP is a reliable stream delivery service that guarantees that all bytes received will be identical with bytes sent and in the correct order. Since packet transfer is not reliable, a technique known as positive acknowledgment with retransmission can be used to guarantee reliability of packet transfers. This fundamental technique requires the receiver to respond with an acknowledgment message as it receives the data. The sender keeps a record of each packet it sends. The sender also keeps a timer from when the packet was sent, and retransmits a packet if the timer expires before the message has been acknowledged. The timer is needed in case a packet gets lost or corrupted.
TCP consists of a set of rules: for the protocol, that is used with the Internet Protocol, and for the IP, to send data “in a form of message units” between computers over the Internet. While IP handles actual delivery of the data, TCP keeps track of the individual units of data transmission, called segments that a message is divided into for efficient routing through the network. For example, when an HTML file is sent from a Web server, the TCP software layer of that server divides the sequence of octets of the file into segments and forwards them individually to the IP software layer (Internet Layer). The Internet Layer encapsulates each TCP segment into an IP packet by adding a header that includes (among other data) the destination IP address. Even though every packet has the same destination address, they can be routed on different paths through the network. When the client program on the destination computer receives them, the TCP layer (Transport Layer) reassembles the individual segments and ensures they are correctly ordered and error free as it streams them to an application.
Hereinafter the TCP segment structure is described. Transmission Control Protocol accepts data from a data stream, segments it into chunks, and adds a TCP header creating a TCP segment. The TCP segment is then encapsulated into an Internet Protocol (IP) datagram. A TCP segment is “the packet of information that TCP uses to exchange data with its peers.”
The term TCP packet, though sometimes informally used, is not in line with current terminology, where segment refers to the TCP PDU (Protocol Data Unit), datagram to the IP PDU and frame to the data link layer PDU.
Processes transmit data by calling on the TCP and passing buffers of data as arguments. The TCP packages the data from these buffers into segments and calls on the internet module (e.g. IP) to transmit each segment to the destination TCP.
A TCP segment consists of a segment header and a data section. The TCP header contains 10 mandatory fields, and an optional extension field (Options, orange background in table).
The data section follows the header. Its contents are the payload data carried for the application. The length of the data section is not specified in the TCP segment header. It can be calculated by subtracting the combined length of the TCP header and the encapsulating IP header from the total IP datagram length (specified in the IP header).
                Source port (16 bits)—identifies the sending port        Destination port (16 bits)—identifies the receiving port        Sequence number (32 bits)—has a dual role:                    If the SYN flag is set (1), then this is the initial sequence number. The sequence number of the actual first data byte and the acknowledged number in the corresponding ACK are then this sequence number plus 1.            If the SYN flag is clear (0), then this is the accumulated sequence number of the first data byte of this packet for the current session.                        Acknowledgment number (32 bits)—if the ACK flag is set then the value of this field is the next sequence number that the receiver is expecting. This acknowledges receipt of all prior bytes (if any). The first ACK sent by each end acknowledges the other end's initial sequence number itself, but no data.        Data offset (4 bits)—specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes, allowing for up to 40 bytes of options in the header. This field gets its name from the fact that it is also the offset from the start of the TCP segment to the actual data.        Reserved (3 bits)—for future use and should be set to zero        Flags (9 bits) (aka Control bits)—contains 9 1-bit flags                    NS (1 bit)—ECN-nonce concealment protection (added to header by RFC 3540).            CWR (1 bit)—Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism (added to header by RFC 3168).            ECE (1 bit)—ECN-Echo indicates            If the SYN flag is set (1), that the TCP peer is ECN capable.            If the SYN flag is clear (0) that a packet with Congestion Experienced flag in IP header set is received during normal transmission (added to header by RFC 3168).            URG (1 bit)—indicates that the Urgent pointer field is significant            ACK (1 bit)—indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set.            PSH (1 bit)—Push function. Asks to push the buffered data to the receiving application.            RST (1 bit)—Reset the connection            SYN (1 bit)—Synchronize sequence numbers. Only the first packet sent from each end should have this flag set. Some other flags change meaning based on this flag, and some are only valid for when it is set, and others when it is clear.            FIN (1 bit)—No more data from sender                        Window size (16 bits)—the size of the receive window, which specifies the number of bytes (beyond the sequence number in the acknowledgment field) that the sender of this segment is currently willing to receive (see Flow control and Window Scaling)        Checksum (16 bits)—The 16-bit checksum field is used for error-checking of the header and data        Urgent pointer (16 bits)—if the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte        Options (Variable 0-320 bits, divisible by 32)—The length of this field is determined by the data offset field. Options have up to three fields: Option-Kind (1 byte), Option-Length (1 byte), Option-Data (variable). The Option-Kind field indicates the type of option, and is the only field that is not optional. Depending on what kind of option we are dealing with, the next two fields may be set: the Option-Length field indicates the total length of the option, and the Option-Data field contains the value of the option, if applicable. For example, an Option-Kind byte of 0x01 indicates that this is a No-Op option used only for padding, and does not have an Option-Length or Option-Data byte following it. An Option-Kind byte of 0 is the End Of Options option, and is also only one byte. An Option-Kind byte of 0x02 indicates that this is the Maximum Segment Size option, and will be followed by a byte specifying the length of the MSS field (should be 0x04). Note that this length is the total length of the given options field, including Option-Kind and Option-Length bytes. So while the MSS value is typically expressed in two bytes, the length of the field will be 4 bytes (+2 bytes of kind and length). In short, an MSS option field with a value of 0x05B4 will show up as (0x02 0x04 0x05B4) in the TCP options section.        Padding—The TCP header padding is used to ensure that the TCP header ends and data begins on a 32 bit boundary. The padding is composed of zeros.        
Some options may only be sent when SYN is set; they are indicated below as[SYN]. Option-Kind and standard lengths given as (Option-Kind, Option-Length).                0 (8 bits)—End of options list        1 (8 bits)—No operation (NOP, Padding) This may be used to align option fields on 32-bit boundaries for better performance.        2,4,SS (32 bits)—Maximum segment size (see maximum segment size)[SYN]        3,3,S (24 bits)—Window scale (see window scaling for details)[SYN]        4,2 (16 bits)—Selective Acknowledgement permitted.[SYN] (See selective acknowledgments for details)        5,N,BBBB,EEEE, . . . (variable bits, N is either 10, 18, 26, or 34)—Selective ACKnowledgement (SACK). These first two bytes are followed by a list of 1-4 blocks being selectively acknowledged, specified as 32-bit begin/end pointers.        8,10,TTTT,EEEE (80 bits)—Timestamp and echo of previous timestamp (see TCP timestamps for details)        14,3,S (24 bits)—TCP Alternate Checksum Request.[SYN]        15,N, . . . (variable bits)—TCP Alternate Checksum Data.        (The remaining options are obsolete, experimental, not yet standardized, or unassigned)        
A number of applications with different quality of service (QoS) needs rely on TCP as an underlying reliable or UDP as an underlying low latency transport mechanism:                High throughput streamed measurement data transport using application specific automotive protocols with data rates in the range of tens of Mbytes/sec on a single TCP connection.        Low latency and low jitter streamed measurement data transport for function in the loop (FIL) prototyping use cases using UDP.        Transaction based control, calibration and diagnostics services with low latency demands to ensure low transaction round trip times using either TCP or UCP.        Standard best effort TCP/IP services like http, ftp or terminal emulation.        
In many cases these applications co-exist on a single embedded acquisition device, and each application specific and service aware automotive protocol requires its own TCP connection.
TCP/IP is mostly implemented in software and runs in the CPU's supervisor mode (kernel space) as an operating system service. However, software based protocol implementations principally suffer from frame rate limitations due to the high amount of context switches and the amount of work that has to be performed for each received or transmitted frame. This is particular true for small embedded systems with restricted CPU performance which are connected to a high throughput, low latency Gigabit Ethernet link with its very high frame rate.
Various methods have been proposed in the prior art up to now in order to improve the ratio of consumed CPU processing power per frame event. The most popular of these methods, are:                Offload engines                    Offload engines try to reduce the number of operations to be performed per IP frame, e.g. by calculating header and payload checksums in hardware.            This approach reduces the amount of processing power per event but it does not reduce the frame rate for the software. The problem of too many context switches persists.                        Interrupt throttling or interrupt concatenation                    The number of context switches is reduced by concatenating the handling for multiple frame arrivals into a single interrupt service action.            Interrupt throttling helps a lot in reducing the number of context switches per time unit. However, because it operates on link layer (Ethernet) level it is not service aware and introduces undesired latency to all services.                        Use of Jumbo Frames                    Jumbo frames are Ethernet frames with an extended length of typically up to 9600 Byte instead of the standard 1518 Byte. This is supposed to reduce the frame rate by allowing larger TCP segment sizes.            Jumbo frames have never been standardized by IEEE 801.3 and are seldom used in local area networks (LAN) and almost never used in conjunction with TCP. They have to be supported at both ends of the link and are not guaranteed to pass every Ethernet bridged or IP routed network. A TCP receiver can even force a Jumbo frame capable TCP sender to send smaller TCP segments by using the corresponding TCP maximum segment size option.                        Multicore Technology                    Parallel packet processing on a multicore CPU improves all-over packet throughput of a computer considerably.            This technology is only beneficial in the case of independent packet conversations. A single conversation like a TCP connection does not profit from multiple cores, because the cores have to respect the packet sequence which finally leads to a serialized processing of packets on multiple cores, which becomes even worse, because the conversation jumps between the cores; the utilization of the CPU core's level 1 caches and system performance degrades.                        Standalone TCP hardware implementations (ASIC or FPGA IP)                    Standalone TCP hardware implementations provide a complete, but monolithic TCP/IP stack implementation in hardware. Such an implementation shows typically a tight integration of TCP and IP functionality towards the link layer network including address resolution protocol (ARP). It offers a simple streamed data interface towards the client layer and a socket like control interface towards connection management.            Client layer data passes these components by value. In order to handle a reasonable number of TCP connections standalone TCP in hardware implementations require sufficient private data storage and a corresponding buffer management for the retransmission and the reorder buffers. Since the data storage and the buffer management are externally not accessible, any service aware client layer (e.g. XCP on Ethernet) must implement its own buffering schemes. This leads to increased memory demands. A high bit toggle rate results in high system power consumption. The tight integration of TCP, IP and ARP into a monolithic component complicates multiplexing and de-multiplexing of hardware based and software based packet traffic.                        
The client layer is one of several application layers, where a user accesses an application. An application may require any type of client. For example, data communication between an ECU and a device (e.g. an embedded acquisition device) is performed in the client layer. The transport layer provides end-to-end communication services for applications within a layered architecture of network components and protocols. For example, data communication between a device (e.g. an embedded acquisition device) and an external personal computer is performed in the transport layer.
The standardized Transport Control Protocol (TCP) is a core component in interface modules required for the reliable transport of measurement, calibration and diagnostics (MCD) data between the ECU and the MCD application software. Upcoming customer data throughput requirements cannot be fulfilled with the current paradigm of software based transport functions in conventional embedded ECU interface modules with a necessarily restricted CPU performance. The same restrictions will apply to the ECUs themselves with the introduction of automotive Ethernet.
The discussion of the available solutions for TCP acceleration shows that none of these solutions solves the specific TCP in hardware problems of an embedded automotive acquisition device. Therefore, it is an object of the present invention to provide for a fast and reliable data transmission between any two devices in a client layer and/or a transport layer of a communication system, wherein the data transmission is performed according to the TCP. In particular, it is an object of the invention to provide for a fast and reliable MCD data transmission between an automotive ECU and a development software tool, for example running on a personal computer.